Learn Git In 15 Minutes


your-user-name.github.io
williamkpchan.github.io

cd personal-website

git init

git remote add origin https://github.com/your-user-name/your-user-name.github.io.git

https://github.com/your-user-name/your-user-name.github.io.git
is the remote URL that refers to the repository you created on GitHub earlier.
Again, you would replace your-user-name with your actual GitHub username.

To specify the repo using Git, we'll have to add the remote and label it as the origin.

The remote is the URL of the repo that will store your site's contents.
The origin is an alias for the remote. You can think of an alias as an abbreviation or a substitute name.
This means that instead of having to always type the lengthy remote URL over and over again, you can simply refer to it as origin later on.

git remote add codecad https://github.com/williamkpchan/williamkpchan.github.io.git
williamkpchan.github.io



If you accidentally make a mistake when adding the remote URL, you can start over and remove the remote with the following command:

git remote rm origin

git config --global user.name "williamkpchan"
git config --global user.email williamkpchan@gmail.com


http://yingcodingrobotics.blogspot.hk/2016/04/learn-gitprojectgit-branching.html

take a moment to generalize:

Use Git commands to help keep track of changes made to a project:

git init creates a new Git repository
git status inspects the contents of the working directory and staging area
git add adds files from the working directory to the staging area
git diff shows the difference between the working directory and the staging area
git commit permanently stores file changes from the staging area in the repository
git log shows a list of all previous commits


When working on a Git project, sometimes we make changes that we want to get rid of. Git offers a few eraser-like features that allow us to undo mistakes during project creation. In this lesson, we'll learn some of these features.

In Git, the commit you are currently on is known as the HEAD commit. In many cases, the most recently made commit is the HEAD commit.

To see the HEAD commit, enter:

git show HEAD

The output of this command will display everything the git log command displays for the HEAD commit, plus all the file changes that were committed.


What if you decide to change the ghost's line in the working directory, but then decide you wanted to discard that change?

You could rewrite the line how it was originally, but what if you forgot the exact wording? 

The command

git checkout HEAD filename

will restore the file in your working directory to look exactly as it did when you last made a commit.


In Git, it's common to change many files, add those files to the staging area, and commit them to Git in a single commit.

For example, say you want to change the character "LARRY" to "LAERTES" in the script. The name currently appears in two files. After you change the name in both files, you could add the changed files to the staging area with:

git add filename_1 filename_2

Note the word filename above refers to the name of the file you are adding to the staging area, such as scene-3.txt.


What if, before you commit, you accidentally delete an important line from scene-2.txt? Unthinkingly, you add scene-2.txt to the staging area. The file change is unrelated to the Larry/Laertes swap and you don't want to include it in the commit.

We can unstage that file from the staging area using

git reset HEAD filename

This command resets the file in the staging area to be the same as the HEAD commit. It does not discard file changes from the working directory, it just removes them from the staging area.

the new Git command to unstage filename from the staging area.

Notice in the output, "Unstaged changes after reset":

M    scene-2.txt
M is short for "modification"

git commit -m "hamlet"


Creating a project is like hiking in a dark forest. Sometimes you take a wrong turn, then another wrong turn. Before you know it, you're surrounded by bears.

Git enables you to rewind to the part before you made the wrong turn and create a new destiny for the project. You can do this with:

git reset SHA

This command works by using the first 7 characters of the SHA of a previous commit. For example, if the SHA of the previous commit is 5d692065cf51a2f50ea8e7b19b5a7ae512f633ba, use:

git reset 5d69206

From the terminal, print out your Git commit log.

Note: If your cursor gets stuck in "git log" mode in the terminal, press "q" on your keyboard to escape.


Let's take a moment to review the new commands:

git checkout HEAD filename: Discards changes in the working directory.
git reset HEAD filename: Unstages file changes in the staging area.
git reset SHA: Can be used to reset to a previous commit in your commit history.
Additionally, you learned a way to add multiple files to the staging area with a single command:

git add filename_1 filename_2


Up to this point, you've worked in a single Git branch called master. Git allows us to create branches to experiment with versions of a project. Imagine you want to create version of a story with a happy ending. You can create a new branch and make the happy ending changes to that branch only. It will have no effect on the master branch until you're ready to merge the happy ending to the master branch.

In this lesson, we'll be using Git branching to develop multiple versions of a resume

You can use the command below to answer the question: "which branch am I on?"

git branch

========
$ git branch
* master
========

In the output, the * (asterisk) is showing you what branch you're on. The project only has one branch at this time.


To create a new branch, use:

git branch new_branch

eg:
git branch this-is-new-branch

Here new_branch would be the name of the new branch you create, like photos or blurb. Be sure to name your branch something that describes the purpose of the branch. Also, branch names can't contain whitespaces: new-branch and new_branch are valid branch names, but new branch is not.


Switch to the new branch with

git checkout branch_name
eg:
git checkout this-is-new-branch

You will be now able to make commits on the fencing branch that have no impact on master. 


For example, to add files to the staging area, use:

git add filename

And to commit, use:

git commit -m "Commit message"


What if you wanted include all the changes made to the fencing branch on the master branch? We can easily accomplish this by merging the branch into master with:

git merge branch_name

In a moment, you'll merge branches. Keep in mind:

Your goal is to update master with changes you made to fencing.
fencing is the giver branch, since it provides the changes.
master is the receiver branch, since it accepts those changes.


What would happen if you made a commit on master before you merged the two branches? Furthermore, what if the commit you made on master altered the same exact text you worked on in fencing? 

When you switch back to master and ask Git to merge the two branches, Git doesn't know which changes you want to keep. This is called a merge conflict.

In the output, notice the lines:

CONFLICT (content): Merge conflict in resume.txt
Automatic merge failed; fix conflicts and then commit the result.

We must fix the merge conflict. 
In the code editor, look at resume.txt. Git uses markings to indicate the HEAD (master) version of the file and the fencing version of the file, like this: 


<<<<<<< HEAD
master version of line
=======
fencing version of line
>>>>>>> fencing

Git asks us which version of the file to keep: the version on master or the version on fencing. You decide you want the fencing version. 

From the code editor: 
Delete the content of the line as it appears in the master branch
Delete all of Git's special markings including the words HEAD and fencing. If any of Git's markings remain, for example, >>>>>>> and =======, the conflict remains. 
Try reloading the page if Git's markings don't show up. 
 -Engage in swordfights with professional pirates such as Smee. 


In Git, branches are usually a means to an end. You create them to work on a new project feature, but the end goal is to merge that feature into the master branch. After the branch has been integrated into master, it has served its purpose and can be deleted.

The command

git branch -d branch_name

will delete the specified branch from your Git project.

Now that master contains all the file changes that were in fencing.


Review the main concepts and commands from the lesson before moving on.

Git branching allows users to experiment with different versions of a project by checking out separate branches to work on.
The following commands are useful in the Git branch workflow.

git branch: Lists all a Git project's branches.
git branch branch_name: Creates a new branch.
git checkout branch_name: Used to switch from one branch to another.
git merge branch_name: Used to join file changes from one branch to another.
git branch -d branch_name: Deletes the branch specified.


So far, we've learned how to work on Git as a single user. Git offers a suite of collaboration tools to make working with others on a project easier.

Imagine that you're a science teacher, developing some quizzes with Sally, another teacher in the school. You are using Git to manage the project.

In order to collaborate, you and Sally need:

A complete replica of the project on your own computers
A way to keep track of and review each other's work
Access to a definitive project version

You can accomplish all of this by using remotes. 
A remote is a shared Git repository that allows multiple collaborators to work on the same Git project from different locations. Collaborators work on the project independently, and merge changes together when they are ready to do so.


Sally has created the remote repository, science-quizzes in the directory curriculum, which teachers on the school's shared network have access to. In order to get your own replica of science-quizzes, you'll need to clone it with:

git clone remote_location clone_name
eg:
git clone git clone my-quizzes

In this command: 

remote_location tells Git where to go to find the remote. This could be a web address, or a filepath, such as:

/Users/teachers/Documents/some-remote

clone_name is the name you give to the directory in which Git will clone the repository.


One thing that Git does behind the scenes when you clone science-quizzes is give the remote address the name origin, so that you can refer to it more conveniently. In this case, Sally's remote is origin.

You can see a list of a Git project's remotes with the command:

git remote -v

Notice the output:

origin    /home/ccuser/workspace/curriculum/science-quizzes (fetch)
origin    /home/ccuser/workspace/curriculum/science-quizzes (push)

Git lists the name of the remote, origin, as well as its location.
Git automatically names this remote origin, because it refers to the remote repository of origin. However, it is possible to safely change its name.

The remote is listed twice: once for (fetch) and once for (push). We'll learn about these later in the lesson.


After you cloned science-quizzes, you had to run off to teach a class. Now that you're back at your computer, there's a problem: what if, while you were teaching, Sally changed the science-quizzes Git project in some way. If so, your clone will no longer be up-to-date.

An easy way to see if changes have been made to the remote and bring the changes down to your local copy is with:

git fetch

This command will not merge changes from the remote into your local repository. It brings those changes onto what's called a remote branch.


Even though Sally's new commits have been fetched to your local copy of the Git project, those commits are on the origin/master branch. Your local master branch has not been updated yet, so you can't view or make changes to any of the work she has added.

We learned how to merge braches before. 
Now we'll use the git merge command to integrate origin/master into your local master branch. The command:

git merge origin/master

will accomplish this for us.


Now that you've merged origin/master into your local master branch, you're ready to contribute some work of your own. The workflow for Git collaborations typically follows this order:

Fetch and merge changes from the remote
Create a branch to work on a new project feature
Develop the feature on your branch and commit your work
Fetch and merge from the remote again (in case new commits were made while you were working)
Push your branch up to the remote for review
Steps 1 and 4 are a safeguard against merge conflicts, which occur when two branches contain file changes that cannot be merged with the git merge command. Step 5 involves git push.


eg:
cd my-quizzes
git branch bio-questions
git checkout bio-questions
open biology.txt and modified
git add biology.txt
git commit biology.txt -m "added question"


Now it's time to share our work with Sally.

The command:

git push origin your_branch_name

will push your branch up to the remote, origin. 
From there, Sally can review your branch and merge your work into the master branch, making it part of the definitive project version.
eg:
git push origin bio-questions

In the output, notice the line:

To /home/ccuser/workspace/curriculum/science-quizzes
 * [new branch]      bio-questions -> bio-questions

Git informs us that the branch bio-questions was pushed up to the remote. 
Sally can now review your new work and can merge it into the remote's master branch.


Congratulations, you now know enough to start collaborating on Git projects! Let's review.

A remote is a Git repository that lives outside your Git project folder. Remotes can live on the web, on a shared network or even in a separate folder on your local computer.
The Git Collaborative Workflow are steps that enable smooth project development when multiple collaborators are working on the same Git project.
We also learned the following commands

git clone: Creates a local copy of a remote.
git remote -v: Lists a Git project's remotes.
git fetch: Fetches work from the remote into the local copy.
git merge origin/master: Merges origin/master into your local branch.
git push origin : Pushes a local branch to the origin remote.
Git projects are usually managed on Github, a website that hosts Git projects for millions of users. With Github you can access your projects from anywhere in the world by using the basic workflow you learned here.



git remote add origin https://williamkpchan.github.io/

git config --global user.name "williamkpchan"
git config --global user.email williamkpchan@gmail.com

lists them a repository with multiple remotes
$ git remote -v

Adding Remote Repositories
add a new remote Git repository as a shortname you can reference easily
git remote add  :